Adam Williamson [Wed, 2 Nov 2022 00:26:29 +0000 (17:26 -0700)]
focus: fall back to old behaviour if we didn't focus anything
8455b9ac74 seems to have introduced a problem where we can wind
up focusing no widget at all if the `while (parent)` loop doesn't
find a widget it can successfully move the focus to. This 'fixes'
that by falling back to doing the previous thing if we make it
all the way through that loop without moving the focus. Thanks to
@coreyberla for a hint to improve the implementation.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Carlos Garnacho [Wed, 2 Nov 2022 16:11:10 +0000 (17:11 +0100)]
gdk/wayland: Fix button mask calculation on button events
There's 2 things broken here:
- The mask was calculated on top of the GDK button (i.e. skipping
4-7 buttons), so GDK_BUTTON4_MASK and GDK_BUTTON5_MASK were not
assigned. This is now calculated on the (continuous) BTN_ evcodes
so it is guaranteed that the next 2 physical buttons (i.e.
back/forward) get these two places in the mask assigned.
- Furthermore, these buttons would be pushed to places in the
modifier mask that they didn't belong to. It is now checked hard
that only the first 5 buttons enable a modifier flag.
Overall, this ensures that no event masks with bonkers values are
forwarded, and that no stale implicit grabs are left after additional
buttons are pressed.
Luca Bacci [Thu, 10 Nov 2022 08:22:02 +0000 (09:22 +0100)]
GdkWin32: Do not use MA_NOACTIVATEANDEAT
GTK knows when a surface is modally blocked and automatically drops
button press and release events, so do not block input in advance
from WM_MOUSEACTIVATE.
Matthias Clasen [Tue, 18 Oct 2022 18:23:22 +0000 (14:23 -0400)]
editablelabel: Defer changes on focus-out
We can get spurious focus-out/-in pairs when
the editable label is in a popover that gets
a Wayland keyboard enter event as a result of
clicking the editable label.
A timeout isn't a great solution, but nothing
better is available right now.
listbase: Grab focus on items instead of container
The container view itself being focusable makes keyboard navigation
slower by adding a useless focus step.
It also means if an item gets removed, the focus jumps back to the view,
instead of jumping to the next item, as seen in nautilus bug report:
https://gitlab.gnome.org/GNOME/nautilus/-/issues/2489
Instead of making the GtkListBase container itself focusable, override
the .grab_focus() vfunc. This way, calling gtk_widget_grab_focus() on
the view container keeps working sucessfully, but focuses the focus
item directly instead.
This is particularly useful to have because applicaiton authors do
not have direct acess to this class's children, so they can't call
gtk_widget_grab_focus() on them directly.
Matthias Clasen [Mon, 17 Oct 2022 19:10:51 +0000 (15:10 -0400)]
window: Don't focus invisible widgets
Only clear a queued move_focus if the widget
we are focusing is actually visible.
This was happening in some cases when popovers
are dismissed by clicking outside, and it was
causing us to miss proper focus updates that
were already queued.
That commit did two things:
1) Move the focus update to after-paint time
2) Change from grabbing focus to the visible parent
to calling move_focus (TAB)
The second part did have the unintended consequence
of moving focus laterally.
Jonas Ådahl [Fri, 30 Sep 2022 07:26:55 +0000 (09:26 +0200)]
toplevel-size: Report zero bounds as infinite
Empty/zero bounds are sent by the Wayland compositor if there are no
valid bounds to report, e.g. if there are no connected monitors. Report
this to GTK, which uses this to clamp calculated sizes, as INT_MAX, so
that clamping isn't done until there are actual valid bounds to clamp
to.
This fixes clients sometimes shrinking to their minimum size during
hotplugs or after having suspended the session.
Jonas Ådahl [Fri, 30 Sep 2022 07:30:30 +0000 (09:30 +0200)]
surface/wayland: Handle no current monitor when calculating bounds
We shouldn't assume there is always a monitor to derive bounds from.
If there is no monitor, pass empty bounds, as this matches what
xdg_toplevel.configure_bounds do in this case.
This is an experiment to see if I can keep up with
doing post-release version bumps, so git snapshots
will always have a different version from released
tarballs.
"left of right" should be "left or right".
There's a small (subjective?) English nit in there as well: I believe
that buttons are placed (for example) "on the right" rather than "at the
right".
There is nothing particularly specific to drawables
in there (and we don't have that concept anymore),
so just name the source file to match the header.
Easier for everybody.
Carlos Garnacho [Sat, 24 Sep 2022 09:45:18 +0000 (11:45 +0200)]
gtkimcontextwayland: Shuffle full resets after IM changes
Doing reset() on the text widgets after commit and delete_surrounding
is still too eager for some IMs (e.g. those that expect being able
to commit text while keeping a preedit buffer shown).
However, reset() is more of a "synchronize state" action on Wayland,
and it is still desirable to do that after changes that do come from
the IM (e.g. requesting the new surrounding text and cursor/anchor
positions). Notably here, the text_input protocol may still come up
with a preedit string after this state synchronization happens.
Shuffle the code so that the text widgets do not reset() the IM
context after text is deleted or committed, but the Wayland IM does
apply its practical effects after these actions happen. This keeps
the Wayland IM fully up-to-date wrt text widget state, while not
altering the ::commit and ::delete-surrounding-text behavior for
other IM context implementations.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5200 Fixes: 5b78fe2721 (gtktextview: Also reset IM context after IM...) Fixes: 7c0a395ff9 (gtktext: Also reset IM context after IM...) Fixes: 52ac71b972 (gtktextview: Shuffle the places doing IM reset) Fixes: 9e29739e66 (gtktext: Shuffle the places doing IM reset)
projects / gtk4.git / log